1. Technical Field
This disclosure relates to the storage of metadata associated with a graphical user interface (GUI) element in a GUI application (GAP), and in particular relates to the migration of the stored metadata from one GUI element in one version of a GAP to a corresponding GUI element in another version of the GAP.
2. Related Art
The relentless pace of advancing technology has given rise to complex computer software applications to help automate almost every aspect of day-to-day existence. Today applications exist to assist with writing novels to filing income tax returns to analyzing historical trends in baby names. One nearly ubiquitous feature of these applications is that they employ graphical user interfaces (GUIs). Another nearly ubiquitous aspect is that the GUI applications (GAPs) require thorough testing prior to release.
Nevertheless, in the past it has been easier to implement the GUI to the application than to thoroughly test the GAP. For GAPs of any significant complexity, the permutations and combinations of GUI elements gives rise to an enormous field of potential commands and command sequences that could have bugs of any severity, from insignificant to critical failure. Exacerbating the problem is that application developers are under pressure to continually add new features, update the GUI, and release new versions of applications. As a result, even if a test script for a prior version of a GAP were adequate, it is rarely the case that the original test script can adequately test the subsequent revised application.
Manually testing large-scale enterprise GAPs is tedious, error prone, and laborious. Nontrivial GAPs contain hundreds of GUI screens that in turn contain thousands of GUI objects. In order to automate testing of GAPs, test engineers write programs using scripting languages (e.g., JavaScript and VBScript), and these testing scripts drive GAPs through different states by mimicking users who interact with these GAPs by performing actions on their GUI objects. Often test scripts simulate users of GAPs, and their statements access and manipulate GUI objects of these GAPs. For example, the statement:
VbWindow(“Login”).VbEdit(“txtAgentsName”).Set “Shawn”
locates a window whose caption is “Login” and that is created by a Visual Basic-based control, then it locates a text box whose name is “txtAgentsName” that is a GUI object whose parent is the “Login” window. By calling the method Set with the parameter “Shawn”, the value of the text box is set to “Shawn”.
Commercial tools such as QTP and Rational Robot help generate test scripts by tracking a user's pointing of a cursor at GUI objects and performing desired actions. These tools generate scripting code that can replay captured user actions. The generated code serves as a skeleton for creating scripts to automate script testing. Test engineers add code to the generated scripts so that these scripts can replay using different input values thereby exercising the complete functionality of the GAP.
Expanding automatically generated test scripts with manually written code to automate tests makes the test script more complex, difficult to understand, maintain, and evolve. Although it is known in advance that the test scripts access and manipulate GUI elements, it is not clear how to detect operations at compile time that lead to runtime errors. Using API calls exported by testing platforms remains a primary mode of accessing and manipulating GUI objects of GAPs, and these API calls lead to various run-time errors in the test scripts. For example, test personnel may use platform API calls incorrectly in the test script source code thereby accessing GUI elements that they did not intend to access.
It is a difficult technical challenge to check test scripts for potential flaws caused by third party API calls that lead to incorrect tests and runtime errors in the test scripts. Furthermore, there are fundamental problems with using API calls to access and manipulate GUI objects. First, the API calls take names and property values of GUI objects as string input parameter variables. The values of these input parameters are often known only at runtime, making it impossible to apply sound checking algorithms. Second, testing platforms export dozens of different API calls, and high complexity of these API calls makes it difficult for programmers to understand which API calls to use and how to combine them to access and manipulate GUI objects. These problems lead to a wide range of bugs in the test scripts, many of which are difficult to detect during the inspection of the test script source code.
A further problem arises because application requirement specifications include high-level concepts that describe GAPs, specifically its GUI objects. Unfortunately, tracing GUI objects of GAPs to these high-level concepts is a difficult problem because programmers do not document these traces. Accordingly, when test personnel create GAPs, they spend considerable time to understand how to use these GAPs by reading documentation and talking to subject matter experts. This crucial knowledge is often lost after test personnel are reassigned to other tasks or quit the company.
One of the perceived benefits of existing approaches to creating test scripts is that type checking is not required since the script code is generated directly from GUIs. For example, given certain GUI objects in a GAP, a testing tool can produce corresponding statements that navigate to these objects using API calls with string parameters describing their properties. However, this perceived benefit in fact gives rise to difficult technical challenges due to semantic inconsistencies between the test script and the GAP. Suppose, for example, that during the maintenance phase the GUI of the GAP changed. The scripting interpreter is not aware of the change and it would run the generated script without producing any compile-time warnings. However, the resulting script either fails at run time or produces incorrect test results because its code attempts to access GUI objects that are either changed or do not exist anymore.
An additional difficulty arises from the management of the enormous amount of data generated in association with each GAP, the different versions of each GAP, and the GUI objects within each GAP version.
Therefore, a need exists for a test script generation architecture with supporting analysis and evaluation logic that addresses the problems noted above and other previously encountered.